Θέλω να ρωτησω τι κινδύνους διατρέχει (τελείως εγκυκλοπαιδικά ρωτάω) το να έχουμε μια εφαρμογή όπου για μια ενέργεια να δημιουργεί κάποιους πίνακες να γεμίζουν κάποια dataset και μετά να τους σβήνει μόλις τελείωνει!!!! Χωρις transaction και ας θεωρήσουμε ότι δεν έχει νόημα το να μπλέξουμε με transactions δεν θα εκτελείτε ταυτόχρονα κάτι απο άλλον!!!

---

select DATEDIFF(dd,GetDate(),'20140731') AS EΠΟΜΕΝΕΣ_ΔΙΑΚΟΠΕΣ

Πέρα από το ότι το create/drop κοστίζει στη βάση ως διαδικασία πολύ περισσότερο από insert/truncate (οπότε σε συνήθες φόρτου καταλαβαίνεις...) δεν μπορώ να σκεφώ κάποιον άλλο κίνδυνο. Εκτός αν το πας κάπου που δεν φαντάζομαι αυτή τη στιγμή. Εγκυκλοπαιδικές ερωτήσεις, εγκυκλοπαιδικές απαντήσεις...

 

---

Vir prudens non contra ventum mingit

Το πραγματικό κόστος της δημιουργίας temporary πινάκων είναι ότι προκαλούν fragmentation στη βάση. Επίσης, ένας πιθανός κίνδυνος είναι ότι ..... πάντα κάποιος άλλος θα βρεθεί να ξανατρέξει την ίδια διαδικασία που δεν έπρεπε να τρέξει και θα βρεθούν δύο να προσπαθούν να πειράξουν τον ίδιο πίνακα! Τέλος, υπάρχει ο πιο πιθανός κίνδυνος να ξεμείνουν οι πίνακες επειδή για κάποιο λόγο διακόπηκε το batch, είτε λόγω χαμένης σύνδεσης, κρεμάσματος της εφαρμογής, πιθανό deadlock, timeout κλπ. Αν μάλιστα σκεφτείς ότι οι temp πίνακες χρησιμοποιούνται κυρίως για batch processing μεγάλης διάρκειας, η πιθανότητα να μείνει κάτι είναι δεν είναι αμελητέα.

Εφόσον υπάρχει πραγματική ανάγκη να χρησιμοποιήσεις temp πίνακες, θα πρέπει να χρησιμοποιήσεις τις δυνατότητες που σου δίνει η βάση σου. Για παράδειγμα, ο SQL Server σου επιτρέπει να δημιουργήσεις temporary tables απλά προσθέτωντας το # στο όνομα του πίνακα. Οι πίνακες αυτοί δημιουργούνται στην tempDB οπότε δεν προκαλούν fragmentation στις βάσεις σου, δημιουργούνται ανά χρήστη οπότε δεν υπάρχει θέμα χρήσης από άλλο batch και τέλος διαγράφονται αυτόματα όταν δεν χρειάζονται πλέον.

Όπως όμως σου είπε και ο Μάνος, πρέπει να μας πεις ΓΙΑΤΙ του θέλεις. Ίσως να μην κάνουν για την περίπτωση σου, ίσως να υπάρχουν άλλες, πιο εύκολες λύσεις, ίσως πάλι να είναι ακριβώς αυτό που ζητάς αλλά ... τί ζητάς?

---

Παναγιώτης Καναβός, Freelancer
Twitter: http://www.twitter.com/pkanavos

Παναγιώτης Καναβός:

Εφόσον υπάρχει πραγματική ανάγκη να χρησιμοποιήσεις temp πίνακες, θα πρέπει να χρησιμοποιήσεις τις δυνατότητες που σου δίνει η βάση σου. Για παράδειγμα, ο SQL Server σου επιτρέπει να δημιουργήσεις temporary tables απλά προσθέτωντας το # στο όνομα του πίνακα. Οι πίνακες αυτοί δημιουργούνται στην tempDB οπότε δεν προκαλούν fragmentation στις βάσεις σου, δημιουργούνται ανά χρήστη οπότε δεν υπάρχει θέμα χρήσης από άλλο batch και τέλος διαγράφονται αυτόματα όταν δεν χρειάζονται πλέον.

---

Manos

Βασικά αυτό που θέλω να κάνω είναι να κρατώ σε 2 πίνακες κάποια αποτελέσματα απο views (τα views είναι πολλά κ ανάλογα με την περίπτωση) ώστε πάνω σ' αυτά να κάνω κάποιους ελέγχους με stored procedures και να εκτυπώνω τα δεδομένα. Το όλο story είναι οτι δεν θέλω να αλλάξω τα αποτελέσματα όπως έρχονται απο τα views απλά μονο για την συγκεκριμένη περίπτωση και εκτός αυτού με αυτό το τρόπο θα έχω και καλύτερους χρόνους δεν θα είναι αργό. Αρχηκά το έκανα με πίνακες όπου μετά την εκτύπωση τους κάνω drop απο την βάση. Αλλά σκέφτηκα μήπως προκύψουν προβλήματα και για αυτό ρώτησα .Θεωρώ ότι με temp tables είναι καλή περίπτωση.

---

select DATEDIFF(dd,GetDate(),'20140731') AS EΠΟΜΕΝΕΣ_ΔΙΑΚΟΠΕΣ

Οι temp πίνακες λύνουν όλα τα προβλήματα που ανέφερε ο Παναγιώτης στο προηγούμενο του post ωστόσο δεν λύνουν το πρόβλημα του performance. Επίσης, πέρα από τα temp tables υπάρχουν και τα table variables μια λύση που αξίζει να τη διερευνήσεις.

Το ερώτημα λοιπόν είναι γιατί δεν μπορείς να δουλέψεις με τις stored procedures απευθείας πάνω στα views και χρειάζεται να ρίξεις τα αποτελέσματα πρώτα σε temp πίνακες; Προσωπικά θα εξαντλούσα πρώτα αυτό το ενδεχόμενο, να δουλέψω πάνω στα views, κατόπιν θα εξέταζα τη λύση των table variables και τέλος τα temp tables. Είναι δύσκολο να είσαι σίγουρος εκ των προτέρων για το ποιά λύση είναι καλύτερη ως προς το performance αλλά τυπικά οι χρόνοι για τις τρεις υλοποιήσεις είναι views < table variables < temp tables. Θα πρέπει να δοκιμάσεις την κάθε μία γιατί εξαρτάται από το σενάριο (μεγάλο/μικρό set από data, κλπ).

 

 

---

Vir prudens non contra ventum mingit

    Πάνω στα views δεν θέλω να δουλέψω γιατί οι stored procedures μεταβάλουν τα δεδομένα που φέρνουν τα views αλλά πέρα απο αυτό τα views δεν είναι ένα ή 2 αλλά πάρα πολλά πάνω απο 20. Την λύση του table variable την έχω χρησιμοποιήσει στο παρελθόν για άλλο λόγω και δεν μπορώ να πω πως με βελτίωσε τους χρόνους αρκετά αισθητά απλά με έβγαλε απο μια δύσκολη περίπτωση αλλά είναι όντως καλή τακτική. Το έχω ήδη όπως αναφέρω κ πιο πάνω με πίνακες και πάει πολύ γρήγορα και παίζει ήδη καλά. Το Θέμα μου ήταν και είναι να δω τους πιθανους κινδύνους του όλου εγχειρήματος . Η αλήθεια είναι ότι το κόστος Create / Drop table κοστίζει και αφού υπάρχει και η δυνατότητα temp tables την οποία δεν την έχω και πολύ συμπάθεια (δική μου αποψη μην την δίνετε σημασία) ίσως να το δοκίμαζα να παίξω με temp tables. Αλλά σε καμία περίπτωση δεν θα έμπαινα στο κόπο να πειράξω / παίξω με τα πολλά views τουλάχιστον αυτή τη στιγμή (μια τέτοια λύση είναι πολύ πιο επιρεπής σε λάθη παρά το οτι είναι ίσως η ορθότερη).

---

select DATEDIFF(dd,GetDate(),'20140731') AS EΠΟΜΕΝΕΣ_ΔΙΑΚΟΠΕΣ

Μάνο,


με ενδιαφέρει και εμένα το θέμα Performance temp tables με table variables. καταλαβαίνω ότι τα temp tables δημιουργούνται στο temp db ενώ τα table variables στην μνήμη.

αλλά δεν κασάρονται oι temp tables στην μνήμη όπως και οποιαδήποτε άλλα data ( ανάλογα βέβαια με την ποσότητα μνήμης ) για γρήγορη πρόσβαση?

τα table variables στην περίπτωση της "λίγης-στρεσαρισμένης  μνήμης" δεν κάνουν χρήση της Temp db?

μπορείς να βάλεις indexes σε table variables? αν όχι, δεν προκύπτει ότι θα έχουμε table scan-bad performance? στα temp tables μπορείς να έχεις μια σειρά από Indexes-improve performance if correctly selected.

Μπορείς να έχεις statistics στα table variables?

πως προκύπτει ότι τα table variables είναι πιο γρήγορα από τα temp tables?

αυτό θα ήτανε ένα καλό post για το sqlschool.gr

---

Νικόλαος Καντζέλης
BSc, MSc, MCAS, MCPD, MCITP, MCTS,MCP, MCT

http://www.nksolutions.gr http://dotnetstories.wordpress.com http://weblogs.asp.net/dotnetstories http://forum.dotnetnuke.gr

Δεν έχει νόημα να τα ξαναγράφω, δες εδώ http://databases.aspfaq.com/database/should-i-use-a-temp-table-or-a-table-variable.html για ένα συγκριτικό. Από εκεί και πέρα, καμιά από τις δύο λύσεις (table variables / temp tables) δεν είναι πάντοτε κι εγγυημένα η καλύτερη. Όπως λέει και στην κατάληξη του άρθρου, χρειάζεται δοκιμή με "reasonable load testing".

 

---

Vir prudens non contra ventum mingit

A, εδώ (http://support.microsoft.com/kb/305977/el) τα λέει πιο συγκεκριμένα:

Q5: Do I have to use table variables instead of temporary tables?

A5: The answer depends on these three factors:

• The number of rows that are inserted to the table.
• The number of recompilations the query is saved from.
• The type of queries and their dependency on indexes and statistics for performance.

In some situations, breaking a stored procedure with temporary tables into smaller stored procedures so that recompilation takes place on smaller units is helpful.

In general, you use table variables whenever possible except when there is a significant volume of data and there is repeated use of the table. In that case, you can create indexes on the temporary table to increase query performance. However, each scenario may be different. Microsoft recommends that you test if table variables are more helpful than temporary tables for a particular query or stored procedure.

Αλλά και πάλι είναι για SQL Server 2000 οπότε δεν θα μου έκανε έκπληξη αν κάτι από αυτά δεν ισχύει στις επόμενες εκδόσεις. Βασικά, μόνο με testing μπορείς να είσαι σίγουρος.

 

---

Vir prudens non contra ventum mingit

Μάλιστα. Οπότε δεν ισχύει ότι η μία λύση είναι καλύτερη όσο αφορά το performance. Είναι στην λογική , it depends.

τα Links , τους έριξα μια ματιά και είναι κατατοπιστικά.

βρήκα και αυτό εδώ

http://sqlug.be/blogs/wesleyb/archive/2008/04/14/table-variable-vs-parallelism.aspx

κάπου εκεί μέσα λέει "was the fact that queries do not go parallel when table variables are involved. "

αυτό όντως είναι θέμα, να μην μπορεί να χρησιμοποιεί ένα multi-CPU μηχάνημα.

και μετά είδα και αυτό το Post που επιβεβαίωσε την υποψία μου ότι δεν είναι τα data pages των tables variables αποθηκευμένα μόνο στην μνήμη αλλά χρησιμοποιούνε και την temp db.

Οπότε κάποιος εκτυπώνοντας όλα αυτά για το αρχείο του καταλαβαίνει τι συμβαίνει με τις 2 αυτές επιλογές.

---

Νικόλαος Καντζέλης
BSc, MSc, MCAS, MCPD, MCITP, MCTS,MCP, MCT

http://www.nksolutions.gr http://dotnetstories.wordpress.com http://weblogs.asp.net/dotnetstories http://forum.dotnetnuke.gr